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(57) Abstract 

A system and method for authen- 
ticating and au^orizing user access to 
a computer network. An AAA server 
comprises a plurality of Authentication 
transport protocol modules that interface 
with one or more clients using a native 
authentication transport protocol. The 
AAA server is coupled with a DBMS 
system that stores user auAentication, 
authorization and accounting informa- 
tion in a standard format. Authentica- 
tion and authorization are performed us- 
ing a five phase process comprising the 
phases: Augmentation; Selection; Au- 
thentication; Authorization and Confir- 
mation. During the Augmentation phase, 
client requests are translated into a stan- 
dard internal format The requests are 
parsed into a set of attribute/value pairs 
according to a parse rules table. In ^e 
Selection phase, the AAA server deter- 
mines the details of the access request 
and identifies the permit required to au- 
thorize access. A rules table is used, wherein a particular row in the rules table is selected according to the attribute/value pairs from the 
Augmentation phase. The rules table provides the necessary details for the AAA server to formulate a proper response to the client. In 
the Authentication phase, the AAA server determines if the log in information provided by the user matches information stored in the user 
record. In the Authorization phase, the AAA server determines if the user is autfiorized to access the requested service by determining 
if the permit retrieved in the Selection phase matches the permit stored in the user database. In the Confirmation phase, the AAA server 
determines if a port limit has been exceed and checks the client request for inconsistencies. 
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Centralized Authentication, Authorization And Accounting 
Server With Support For Multiple Transport Protocols And 

Multiple Client Types 



Background of the Invention 

Field of the Invention 

The present invention relates generally to authentication, authorization and 
accounting systems, and more particularly to a centraUzed general purpose 
authentication, authorization and accounting server with support for multiple 
authentication transport protocols and multiple client types. 

RelatedArt 

Security is a major and continuing concern for managers and 
administrators of computer networks. For financial and security reasons, it is 
vitally important that only authorized users have access to the network. 
Additionally, access must be controlled so that users can only connect to systems 
and services in which they are entitled. For tracking and billing purposes, it is 
important to document the time users are logged onto the network and the 
services that are used. Finally, there is often a need to limit the number of times 
a user can simultaneously log onto the network. 

Conventionally, each type of client provides a unique form of security for 
guarding against xmauthorized break-ins and for controlling user access. For 
example, UNIX-type operating systems generally provide a user identification 
(UserlD) and password scheme for authenticating pre-authorized users. Such 
systems also provide the ability to assign specific access rights for each user that 
is authorized to access the system. Generally, data associated with pre-authorized 
users and flieir corresponding access rights are stored in a database on each client. 

Other types of clients provide similar types of security measures using 
some form of a User ID and/or Password for authentication purposes. Sometimes 
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encryption schemes are used to increase the level of security. Each client also 
provides an authorization mechanism to control user access to specific systems 
andservices. Generally, each client maintains a separate database to store the user 

authentication and authorization information. 

GeneraUy, modem computer networics employ a variety of cUentlypes and 
have multiple points of access. For these networks it can be very difficult to 
manage, maintain and update user authentication and authorization mformation 
because such information is distributed among separate databases in a variety of 
cUents. lnaddition,valuablestorageresourcesarewastedbecauseuserdatamust 
be dnpUcated among the different cUent databases. This problem is multipUed 
when large networks with many points of access are implemented. 

One solution to this problem is the use of distributed security servers. An 
example of adistributed security server istheRemoteAuthenticationDial-InUser 
Service (RADIUS), provided by Livingston Enterprises. Inc. of Pleasonton 
California. Dislributedsecurityserverscreateaanglecentralizedlocationforuser 
authentication and authorization data. In this feshion, all user data is stored in a 
single location to faciUtate the task of maintaining and updating user data. 
Further, by having all tiie data m one location, storage space is preserved because 
there is no need to dupUcate user data on multiple machines. 

Conventional distributed security servers are problematic m tiiat they are 
designed to work with particular types of hardware and particular types of 
operating systems (i.e. cUent types). In addition, conventional security servers 
generally support a specific authentication transport protocol. Examples of 
authentication transport protocols m use today are: RADIUS transport protocol, 
provided by Livingston Enterprises, Inc.; Networic hiformation Service (NIS), 
provided by SUN Microsystems Inc.; Kerberos, provided by tiie Massachusetts 
Institute of Technology; Microsoft Domain System (MDS), provided by 
Microsoft, Inc.; and AppleTalk by Apple Computer, Inc. 

For many large computer networks, a variety of authentication transport 
protocols may be m use. For tiiese networks, conventional security servers are 
inadequate to handlethediffeienttypesofauthenticationtransport protocols being 
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used by clients on the network. Thus, multiple security servers must be used, or 
client software must be altered to support the authentication transport protocol 
being supported by the particular security server being used. The latter solution 
may not be possible for some client types. For example, it may not be possible to 
support Kerberos on a Macintosh computar system. 

Additionally, conventional security systems typically only support specific 
types of operating systems. Examples of different operating systems include 
UNIX operating systems, Microsoft operating systems (Windows 95, Windows 
N/T and DOS) and Macintosh operating systems. For these networks, 
conventional security servers are inadequate to handle the variety of operating 
systems being used. 

StUl fimher, conventional security servers typically svqjport authentication 
and authorization ftmctions, but not accounting ftmctions. Generally, user data 
used by convaational security servers is stored in a propriety format. For these 
systems, separate accounting databases and accounting systems are typically 
maintained. This is a waste of resources because mudi of the same data is used 
by both accounting and security systems. Therefore, it would be desirable to 
mamtam a single database for both the accounting information and the user 
authentication and authorization information. 

Accordingly, what is needed is a distributed security system capable of 
supporting a variety of authentication transport protocols used by a variety of 
client types and is capable of supporting accounting ftmctionality from the same 
database used to store user axithentication and authorization informatioiL 

Summary of the Invention 

Accordingly, the present invention is directed toward an Authentication, 
Authorization and Accounting server (AAA server), that is capable of supporting 
a variety of authentication transport protocols from a variety of client types. The 
AAA server of the present invention includes a standard database management 
system (DBMS) that stores user authentication and authorization data in a 
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standaidfotmat Accounting information and reports are storwi and derived from 
the same DBMS used for authenticating and authorizing user access. 

The AAA server of the present invention comprises a plurality of 
authentication transport protocol modules ("support modules"). Support for 
specific authentication transport protocols is contained within each support 
module. Each support module is coupled to one or more clients that request 
access to the network using a particular authentication transport protocol 
corresponding withthe associated supportmodule. In this fashion, supportforthe 

AAA serverofthepresentinventionis transparent to the cUents requesting access 
to the networic. 

Each support module is coupled with an Accounting and Authorization 
module (AAmodule). The AA module is coupled with the DBMS and perfonns 
authentication and authorization functions on behalf of tixe cUents using a novel 
five phase process. The five phase process comprises tiie foUowing phases: 
Augmentatioi^ Selection; Authentication; Authorization and Confirmation. 

During tiie Augmentation phase, cUent requests are translated into a 
standard internal format used by the AAmodule. The requests are parsed into a 
setofattribute/valuepairsaccordingtoaparseniles table. An attribute/value pair 

is referred to as a tiiple. A complete set of tuples associated witii a particular 

client request is referred to as a tuple vector. 

IntiieSelectionphase,theAAmoduledeterminesthedetailsoftheaccess 

request In addition, a specific pennit is extracted from a rules table. Thepermit 
is used later during tiie Authorization phase to be sure tiie particular user making 
flie request is autiiorized to access tiie requested service. A rules table is used, 
wherein a particular row in tiie niles table is selected according to tiie 
attribute/value pairs from tiie Augmentation phase. The rules table provides tiie 
necessary details for tiie AA module to fonnulate a proper response to tiie client. 

In tiie Autiientication phase, tiie AA module detennines if tiie log-in 
infonnation provided by tiie user matches information stored in tiie user record. 
SpecificaUy. tiie DBMS is queried and tiie user record is retrieved. If tiie user 
record matches tiie information (such as UserlD and password) provided by tiie 
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user, the request is authenticated. If not, a reject message is sent to the client and 
the user is denied access to the network. 

In the Authorization phase, the AA module determines if the user is 
authorized to access the requested service by determining if the permit retrieved 
during the Selection phase matches the permit stored in the user database. 

In the Confirmation phase, flie AA module determines if a port limit has 
been exceeded to prevent a user may &om simultaneously logging onto the 
network more than a specified number of times. In addition, sanity checks, such 
as examining the client request for inconsistencies, are performed during flie 
Confirmation phase. 

Accounting data is stored in the DBMS system by the AAA server as 
required. Reports are generated by the AAA server of the present invention by 
accessing the DBMS for accotmting information. This can be used for billing 
purposes and the like. 

Brief Description of the Figures 

The present invention is described with reference to the accompanying 
drawings, wherein: 

FIG. 1 is a block diagram depicting an example operational environment 
according to an embodiment of die present invention; 

FIG. 2 is a block diagram showing the details of the AAA server according 
to an embodiment of the present invention; 

FIG. 3 is a flowchart depicting a five phase process that can be used by the 
AA module, according to an embodiment of the present invention; 

FIG. 4 is an example of a parse rules table according to an embodiment of 
the present invention; 

FIG. 5 is an example of a rules table according to an embodiment of the 
present invention; and 

FIG. 6 is a block diagram of a computer usefiil for implementing 
components of the present invention; 
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DeiaUed Description of the Preferred Embodiments 

FIG. 1 is a block diagram depicting a typical operational environment 
according to one embodiment of the present mvention. An embodiment of the 
present invention is typically used by corporate network managers. Internet 
Service Providers GSPs) and the like. In FIG. 1. a computer network 102 is 
depicted. In this example, thecomputernetwork 102 comprises two local area 
networks (LANs) 102a and 102b. The two LANs 102a and 102b are coupled 
together via a router 122. TTie type of network 102 depicted in this example 

embodunent is referred to as a wide area network (WAN). 

Thecomputernetworkl02isshownforiUustmtivepurposesonly. Other 

types of computer networks having different configurations can be used in 
alternate embodiments of the present invention. For example, a single LAN or 
multipleLANscomiectedtogetherviaoneormoreroutersorsimilardevice(s)can 

be used. In feet, any type of computer network can be used with the present 
invention. 

Several types of network elements are depicted as being attached to the 
computer network 102. Some of these network elements represent services that 
are availableto users havmgaccessto the networkl02.Otherelements perform 

thefunctionofcomiectinguserstothecomputernetworkl02. Somenetwork 

elements perform both of these functions. 

Anembodimentof&epresentinventionisiepresentedbythecombination 

of anAulhentication, AuthorizationandAccountingserver(AAAserver) llSand 
adatabasemanagementsystemCDBMS) 120. In this example, the DBMS 120 
and the AAA server 118 are depicted as being embodied m separate devices or 
"boxes." This may not always be the case. In alternative embodiments the AAA 
server 118 and the DMBS server 120 can reside in a single device. 

Likewise, the configuration and airangemem of other network elements 
shown in FIG. 1 , are arbitrary and are depicted as separate boxes for convenience 
only. Alternate configurations may combine more than one element in a single 
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box, including the boxes used to describe the AAA server 1 1 8 and/or the DBMS 
server 120. Any such alternate configurations are within the scope and spirit of 
the present invention. 

Many types of database systems can be used for the DBMS server 120 
5 according to a preferred embodiment of the present invention. Preferably, a 

structured query language (SQL) relational database management system is used. 

The DMBS server 120 is used to store and retrieve user account information, 
biUing information, usage statistics and oflier user data. Examples of DMBS 
systems that can be used with the present invention include commonly avaUable 
10 systems from Informix, Microsoft, Oracle and Sybase. 

The AAA server 1 1 2 performs security and accounting services for several 
of the network elements depicted m FIG. 1 . The network elements that request 
security and accounting services from the AAA server 1 1 8 are referred to herein 
as "^Uents." whUe the AAA server 118 (along with the associated DBMS server 
15 120) are refwrcd to herein as "servCTS." 

The clients depicted in this example are: a UNIX device 106; a general 
mail device 108; a Microsoft (MS) device 1 10; a network access server device 
(NAS) 112; a general news device 1 14; and a World Wide Web (WWW) device 
116. The MS device 110 can be any computer system running a Microsoft 
20 operating system, such as Windows 95 or Windows N/T. 

The NAS device 1 1 2 is connected to a plvirality of workstations 1 28 via 
telephone lines and a switched telephone network 124, The function of the NAS 
device 1 12 is to provide access for dial-in users at the workstations 128. 

Typical computer networks, such as the computer network 102, comprise 
25 multiplepoints of access. Inthis example, users can access the computer network 

102 from any of the clients 106-1 16 depicted m HG. 1 . For example, users can 
directly or remotely log onto the UNIX client 106. the MS client 110 and/or the 
WWW client 116. 

Users can generally request access to services from any of the available 
30 access points. For example, users directly or remotely connected to the UNIX 

device 106 can access the news device 1 14. the WWW device 1 16 or the mail 
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device 108. Likewise.«sersdialedil«othenetworkvi.theNASdevicen2.can 
^ fte UNK device 106. fte mdl deviee 108. a« MS device no or «.y of 

the other services depicted in HO. 1 . The configuration of access pomts mi 
sendees «=«ssible th«eftom. depends on each specific iniplemertation of the 
eo^nrtworknsedvdththepresentinvention. Such configur«ions v«,nld 

be qiparent to those sldlled in the relevant ar<s). 

•n,e AAA saver 1 1 8 functions to secure access to the computer network 
1 02 against un«.fl«rized »»e»s. Tl» foUovrfng is an example that describes the 

invendon in t«ms of its g«»ral fUnctiondi., as a distributed secur«jr 



server. 



AHuserauthendcationfflKlna^rlcserviceaccessinformationtobeused 
by the AAA server 1 1 8 is s««d fa a standard format within the DBMS server 
120 TOsinfemiatioB is typically entered by system «3ministrators or the hke. 

Commumcation servers, such as the UNIX device 106. 4e maU device 108. the 
KAS device 1 12. the news device 1 1 4, the MS device 1 10 and the WWW device 

116 operrte as cBenls «, the AAA server 118. n.e cheats 106-116 send 
avttenticdon requests to the AAA s«ver 118 and act according «. answers 

received ftom. the AAA server 118. 

Hie AAA server 118 authenticates users through a series of 
communications between the cUents 106-116 and the AAA server 118. Once a 
user is authenticated, the cUents 106-116 provide users with access to the 
appropriate network services. The following is an example of a typical 
authentication process using the AAA server 118 according to a preferred 
embodimentofthepresentinvention.Inthisexample,auserrequestsaccesstothe 

network 102. from a workstation 128 connected to the NAS device 112. 

Using a modem (not shown) from a remote location at one of the 
workstations 128. a user dials into a modem (not shown) connected to the NAS 
device 112. Once this modem to modem comiection is complete, the NAS 112 
prompts Ihe user for a name and password. 

The NAS 112 creates a data packet to form an authentication request. 
THspacketincludesinformationidentifyingtheparticularNAS 1 12 sending the 
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authentication request, the port being used for the modem connection, and the 
user name and password provided by the user.. 

For protection from eavesdropping, the NAS client 112 encrypts the 
password before it is sent to the AAA server 11 8 . Any type of encryption process 
can be used. Typically, an encryption key, that is known to the cUents and the 
AAA server 1 18 is used to decrypt the message. The encryption key is referred 
to herein as a shared secret between the AAA server 11 8 and the various clients 
106-116. 

the Authentication Request is sent over the WAN 1 02 from the NAS 1 1 2 
to the AAA server 1 1 8. When the Authentication Request is received, the AAA 
server 1 18 validates the request and decrypts the data packet, using the shared 
secret, to access flie user name and password information. 

Communications between the AAA server 1 18 and the NAS client 112 is 
performed using a specific authentication transport protocol. In a preferred 
embodiment, the authentication transport protocol is an ^pUcation specific 
TCP/IP protocol. Examples of authentication transport protocols mclude 
RADIUS, NIS. Kerberos, MDS, and AppleTalk. In this example, RADIUS is 
used as the authentication transport protocol between the NAS 1 12 and the AAA 
server 118. 

In order to determine if the user name and password are correct, the AAA 
server 118 performs a database query on the DBMS 120. If the user name and 
password are correct, the AAA server 118 sends an "Authentication 
Acknowledgment" to the NAS 112. The Authentication Acknowledgment 
typically includes information about the user's network system and service 
requirements. This information is provided from the data retrieved from the 
DBMS 120. 

For example, the AAA server 1 18 tells the NAS 1 12 that the user needs 
TCP/IP and/or NetWare using Point-to-Pomt Protocol (PPP) or a Serial Line 
Intemet Protocol (SLIP) to connect to the network 102. The Acknowledgment 
can also contain filtering information to limit a user's access to specific resources 
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on the network 102. Such access rights are provided ftom the information 
retrieved ftom the DBMS 120 query. 

If at any point in this log-in process conditions are not met, the AAA 
server 118 sends an "Authentication Reject" to the NAS 112 and the user is 
denied access to the network 102. 

To ensure that requests are not responded to by unauthorized hackers on 
the network 102, the AAA server 118 typicaUy sends an authentication key. or 
signature, that identifies itself to the NAS 112 client Once this information is 
received by the NAS cUcnt 1 12, it enables the necessary configuration to deliver 
the rigiht network services to the user. 

FIG. 2 is a block diagram depicting details of the AAA server 118, 
according to a preferred embodiment of the present invention. In this example, 
the AAA server 118 provides AAA services for three UNIX clients 206, 210 and 
210, one NAS cUent 204, and one Microsoft N/T client 208. User data 236 is 
available to the AAA server 1 1 8 ftom the DBMS server 120. 

An important feature of the present invention is that it provides a means 
for supporting multiple authentication transport protocols. Further, the present 
inventionprovides an ef&cientmeans for adding support for additional protocols 

as required. This is accomplished, in part, by providing support for different 
protocols in separate modules referred to herdn as authentication transport 
protocol support modules (or "support modules"). 

In this example, four specific authentication transport protocols are 
supported. Accordingly, the AAA server 1 18 comprises four support modules: 
a RADIUS module 230; a Microsoft Domain module 228; a Kerberos module 
226; and an NIS modxile 204. 

Programming support for each authentication transport protocol is 
completely contained within a corresponding authentication transport protocol 
support module. As will be described in detail below, the AAA server 118 
(specificaUy, the AA module 232), uses an internal standard format for 
representingcUentrequestsandforconstructingclientresponses. In this fashion, 
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AAA processing is generalized and does not depend on any particular transport 
protocol. This faciUtates support for multiple authentication transport protocols. 

Accordingly, in the example, the RADIUS module 230 accepts RADIUS 
requests from the NAS 204 and UNIX 206 clients. RADIUS requests are 
5 translatedtoaninteinalformatbytheRADIUSmodule230forprocessmgbythe 

AA module 232. After processing by the AA module 232. a response or answer 
is sent to the RADIUS module 230, where it is converted to a RADIUS message 
and sent to the NAS 204 or UNIX client 206. 

Similarly, the MS Domain module 228 accepts MS Domain requests from 
10 andsendsMSDomainans\verstotheMSNn'client208. The Kerberos module 

226 accepts Kerberos requests from and sends Kerberos answers to the UNIX 
client 210. The NIS module 204 accepts NIS requests from and sends NIS 

answers to the UNIX client 212. 

In this fashion, each of the clients 204-212 communicate with the AAA 

15 server 118 in their native protocol. This has the advantage of allowing 

conventional software to be used within each client 204-212 with little or no 
modification. lnotherwotds,supportfortheAAAserveroftheptcsentinvcntion 

is transparent to the clients 204-212 and are automatically supported. Th^ 
the softwaremodule214within the NASclient204 needs littleor no modification 

20 to be compatible with the AAA server 1 1 8 according to a preferred embodiment 

of the present invention. Likewise, tiie software modules 216, 218, 220 and 222 
within the cUents 206, 208, 210 and 212, respectively, need littie or no 
modification to work witii the AAA saver 118. 

The AA module 232 performs AAA functions in five phases as follows: ( 1 ) 
25 Augmentation; (2) Selection; (3) Authentication; (4) Authorization; and (5) 

Confirmation. This five phase process is described in detail below with reference 
to FIG. 3 . User data, including User IDs, passwords, accounting information, and 
access rights, etc. are stored in the DBMS 120. This information is input by a 
system administrator or the like. Accounting information pertaining to user access 
30 times and services accessed is stored by the AAA server 1 1 8 in tiie DBMS 120. 
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FIG. 3 is a flowchart depicting a five phase process that can be used to 
implement the AA module 232. according to a preferred embodiinent of the 
presentinvention. The process begins with step 302, where control immediately 
passes to step 304. In step 304. the Augmentation phase is performed. 

In the Augmentation phase 3 04. cUent requests are parsed and organized 
into a standard internal format used by the AA module 232. Once a request has 
been augmented, there is no longer a difference between requests sent ftom 

di^nt types of cUents using different authentication protocols. 

Generally. cUent requests are received by the AA module 232 as a single 

string of characters. The Augmentation phase 304 creates standard internal 
representationsusingaparserulestable304thatisg«ierallystoredintheDBMS 
120 Theparserulestable304istypicallydefinedbyasystemadministratoror 
the like according to the needs of each impl«nentation of the present invention. 
In a preferred embodiment of the present mvention, user mterfece tools are 
provided to create and/or customize the parse rules table 304. 

Preferably, cUent requests are represented as fixed attribute/value pairs 
referredtohereinastuples. An example of a tuple is: "CLIENT=UNIX". Aset 
of tuples associated with a particular user is referred to as a tuple vector. An 
example of a tuple vector is the following set of tuples: "CLIENT=UNIX; 
USER-BOB;PASSWORD=XYZ;SERVICEp=SLIP;SERVICE_REQ=ADMIN; 

CALLING_NO=555.2222;CALLED_NO=555.2323Mnthisexample.thetuple 
vector consists of tuples that describe the cUent type, the user ID and password, 
the service selection, the service request, the calling telephone number and the 

called telephone number. 

The parse rules table 304 is used to parse the cUent request into a tuple 
vector. The rules are based on expected requests ftom each cUent supported by 
each implementation of the present invention. The parse rule table 304 is 
customizedaccordmgtosuchexpectedrequests. In some implementations it may 
not be required to parse a cUent request because such requests are aheady in a 
parsed format suitable for the next phase of the process (described below), in 
which case the Augmentation phase 304 is skipped. 
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The amount of parsing required during the Augmentation phase 304, 
depends onthe type andformatofinformationsentby each particular clientbeing 

supported by an embodiment of the present invention. It is important to 
understandthattheuseoftheparse rules table303intheAugmentationphase304 

enables the present invention to be compatible with all types of clients and cUent 
software. This includes conventional or proprietary software running on the 
client Theparserulestableenablesusersofthepresentinventiontotransformany 
type of client request into a format that is compatible with subsequent AAA 
processing (described below) of the present invention. 

FIG. 4 depicts an example of a parse rules table referred to as 
"imp.radhis.parse" 40 1 . This is an example of a parse rules table that can be used 
during the Augmentation phase 304 to analyze information suppUed by the user 
at log-in. 

The user log-in information is compared against the rules table 303 from 
the top line 402 to the bottom line 410. Preferably, the parse rules table 303 is 
structured so that the order of comparison is from the most specific rule to the 
least specific rule. 

In this example, the parse.rules table 303 comprises five rules, each on a 
separate line 402-410. The symbols used in this example are defined as follows: 

"(.)" indicates one character. 

"(.+)" indicates one or more characters. 

"$1", "$2", and "$3" symbols indicate which character set is being 
specified. 

As shown in FIG. 4, the first rule 402 is as follows: 

(.+)©(.+):(•+) Parsed-User="$l", Parsed-Proxy="$2", Parsed-Selectot="$3" 

A log-in request sent by a client matches the first rule 402 if it can be 
parsed into three sets of characters as follows: 
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• one or more characters preceding an @ sign; 

. oneormorecharacteisafterthe@signandprecedingacolon(":");and 

• one or more characters after the colon. 

If there is a match, the first set of characters is taken as the usemame. the 
second set as the proxy server, and the third set as the service requested, or 
service selector. For example, if the user logs in as sequoyah@cherokee:ppp, 
the first rule 402 is matched. The rule determmes that user sequoyah must be 
authenticated at the server caUed Cherokee for authorization to use the ppp 
service. TTie foUovang t.q)les are created as a result of this request: 
USER=sequoyah. DOMAIN=cherokee, SERVIC&TPP. Note that additional 
tuples that complete the tuple vector may also be created, such as tuples that 
identify the cUent making the request, the called telephone number, the calling 
telephone number, etc. 

The second rule 404 depicted in FIG. 4 is as follows: 
(.+)©(.+) Parsed-User="$l". Parsed-Proxy="$2" 

A log-in sent by a cUent matches the second rule 404 if it can be parsed 
into two sets of diaracters as follows: 



25 



• one or more characters preceding an @ sign 

• one or more characters after the @ sign 



30 



If there is a match, the first set of characters is taken as the usemame and 
the second set as the proxy server. For example, if the user logs in as 
buulinh@nhatrang, the second rule 404 is matched. The rule detemunes that 
user buulinh must be authenticated at the server called nhatrang. Because a 
service is not specified ux the log-in, the default service selector is used to 





wo 99/66400 



PCT/US99/13653 



-IS- 



IS 



20 



detennine the service is requested. The following tuples are created as a result of 
this request: USER=buulinh, DOMAIN=nhatrang. 

Note that additional tuples that complete the tuple vector may also be 
created, such as tuples that identify the cUent making the request, the called 
telephone number, tiie calling telephone numba, etc. 

The third rule 406 depicted in FIG. 4 is as follows: 

(.+):(.+) Parsed-Usei:="$l", Parsed-Selector="$2" 

A log-in sent by a client matches the third rule 406 if it can be parsed mto 
two sets of characters as follows: 

• one or more charact^ preceding a colon 

• one or more charact^ after the colon 

If there is a match, the first set of characters is taken as the usemame and 
the second set as the service requested, or service selector. For example, if the 
user logs in as dinh:ppp, the third rule 406 is matched. This rule determines that 
user dinh must be avithenticaled and is requesting authorization for ppp service. 
The following tuples are created as a result of this request: USER=dinh, 
SERVICEF=ppp. Note that additional tuples that complete the tuple vector may 
also be created, such as tuples that identify the client making the request, the 
called telephone number, the calling telephone number, etc. 

The forth rule 408 depicted in FIG. 4 is as follows: 



!(.+) Parsed-User="$l", Parsed-Selectoi=' 



"admin' 



30 



A log-in sent by a client matches the fourth rule 408 if it can be parsed into 
a single set of characters as follows: 



10 
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• one or more 



characters following an exclamation point or bang sign (!) 



If there is a match, the character set is taken as the usemame. For 
example,iftheuserlogsinas!buulinh.thefourthrule408ismatched. This rule 
determines that user buulinh is requesting authentication. In this example, 
because the bang sign ("!") is used, the service selector is set to admin. The 
foUowing tvq)les are created as a result of this request: USER=buulinh, 
SERVICE_REQ=admin. 

Note that additional tuples that complete the tuple vector may also be 
created, such as titles that identify the cUent making the request, the called 
telq>hone number, the calling telephone number, etc. 



The fifth rule 410 depicted in FIG. 4 is as follows: 
15 (.+)Parsed-Usei="$l" 

The log-in matches the fifth rule if it can be parsed into a single set of 
charactras as follows: 

20 • one or more characters 

If there is a match, the character set is taken as the usemame. For 
example, if the user logs in as sequoyah. the fifth rule 410 is matched. Hiis rule 
detennines that user sequoyah is requesting authentication. The foUowing tuple 
25 iscreatedasaresultofthisrequest:USER=sequoyah. Note that additional tuples 

that complete thetuplevectormay also be created, such as tuples thatidentify the 

cUent making the request, the called telephone number, the calling telephone 
number, etc. Because no service is specified in the log-in, the default service 
selector will be used to determine what service is requested. 
3Q As stated, the parse rules table 303 is structured so that the order of 

comparisonis ftomthemostspecificruleto the least specificrule. The reasonfor 
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this should now be evident from the above example. For instance, in the above 
example, if the order of rules were reversed, (i.e. the fifth rule 410 appears at the 
top of the table 303), iall of the above example log-in requests would have 
matched the first rule. 

This is because all that is required by rule 410 is a log-in comprisuig one 
or more characters. All of the examples presented above have at least that 
characteristic in common. Thus, if rule 410 were to appear at the top of the Ust, 
a match would be found immediately upon processing the first row of the table 
303. and no further processing would take place. Thus, it is important that the 
most specific rules are presented before the less specific rules in this example 
implementation of processing a parse rules table 303. 

It shouldbe noted that in aprefeired embodiment, if the components in the 
client request do not match any of the rules in the parse rules table 303, a reject 
message is sent to the client and the user is prevented fi»m accessing the network 
102. 

Referring back to FIG. 3, after the Augmentation phase 304 is complete, 
control passes to step 306. In step 306 the Selection phase is performed. In the 
Selection phase 306, the process determines the details of the access in which the 
user is requesting and identifies the permit 307 required to authorize such access. 
If a particular service was not parsed during the Augmentation phase 304, a 
defeult service is typically used for the Selection phase 306. 

In a preferred embodiment, a selection of a particular service is 
accomplished by selectmgaparticularrowinarulestable 305. Eachrow defines 
a particular service being offered. Data in the rules table is used to construct a 
response to the client. The rules table 305 is typically defined by a system 
administrator or the Uke according to the services provided by each 
implementation of the present invention. In a preferred embodiment, user 
interface tools are provided to create and/or customize the rules table 305. An 
example of a rules table 305 that can be used with the present invention is shown 
innG.5. 
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In this example, the AAA server 1 1 8 of the present invention uses a rules 
table 305, referred to as"imp.radius.niies" 501 to mter incoming requests and to 
define services offered. Ilie rules table 305 is used to implement specific access 
poUcies. Theuserauthorizationrequestiscomparedagainsttherulesfiromthetop 
5 line 506 to the bottom line 526 of the table. Preferably, the rules table 305 is 

structured so that the rule that matches the most common requests is compared 
first, then the next most common, and so on. 

The imp.radius.rules table 305 is structured as a look-up table with an 
inputsectionandanoutputsection. The input section is used to match incoming 
10 requests(asparsedbytheAugmentationphase304)withaparticularrowinthe 

rules table 305. The output section is used to formulate responses to cUents 
comprising appropriateparameterssothatcUentcancorrectlyset-uptherequested 

access. The input section comprises the two columns 536 and 538. Theoutput 
section comprises four columns 528, 530, 532 and 534. 
15 In the Selection phase 306, a single row ftom the rules table 305 is 

selected. The selectionis based onmatchingtuplesfiromtiieAugmentationphase 

304, witii one or more values in the input section 536 and 537 of aparticular row. 
For example, inone implementation, the Selectionphase306 examines the 

service request tuple and searches the rules table for tiie first instance of tiie 
20 particulars«viceintiieselectinputcolumn536. The select column 536 indicates 

the service selector that is being requested. Once a match is found, tiie process 
examines tiie remaining attributes intiie checks column 538 to determine if tiiey 
match tiie tijples in tiie tuple vector. If a match if found, tiiat row is selected. 

The checks column 538 contains tiie attribute- values tiiat correspond witii 
25 tiierequestsentbytiiecUent The AAA server 118 processestiie service selector 

and its corresponding attribute-value pair to determine tiie precise service tiie user 
is requesting in order to formulate a response for tiie client. For example, line 
510 corresponds to a PPP connection on an asynchronous port at 56Kbps. In 
anotiier example, line 518 corresponds to a PPP connection on an ISDN port. 
30 The analysis of the input section determines a set of corresponding output 

values. The proxy column 528 enables a remote or proxy AAA server 1 1 8 to be 
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called if specified. For example, if a user logs in as bob@ic:ppp, the user is 
requestingaccesstoaproxy service "ic" asindicatedinrow506. In this example, 
the user must call the specified telephone number in the checks column 538 
specified in row 506 to be authorized for the projqr service. 

The permit column 528 lists the permit (see 307 in FIG. 3) required to be 
held by the user to be authorized for the requested service. The permit 307 is 
extracted fiom the matched row m the rules table 305 and later checked against 
the permit stored m user databaise table 309 during the Authorization phase 3 1 0, 
as described below. The service ou^ut column 532 provides a label that is 
referenced by the AAA server 1 18 to bill the customer for services received. 

For example, siq)pose a client request is received with the following log-in 
information: gracie:ppp and the usa: has dialed in on an ISDN line. The result 
of the Augmentation phase 304 is a tuple vector that contains at least the 
following tuples: USER=giacie, SERVICB-ppP. andNAS_PORT_TYPEF=ISDN. 

In this example, the checks column 538 is seardied for an instance of 
"ISDN". The result of atop-to-bottom search of ibc rules table 305 is a match at 
row 518. Therefore, m this example, line 51 8 is selected and flie output set from 
row 518, columns 530, 532 and 534 is used to formulate a response to client. 

Inthis example, the permit 518 "isdn-ppp" (row 5 18) is retrieved and will 
be used in a later step to authorize the user. As described below, this will be used 
in the Authorization phase 3 10 to check that the user gracie is authorized to use 
this particular SCTvice. 

If it is lata- determined that user is authorizsed, her session will be 
configured for PPP onlSDN. The user wiU be bUled forthe ISDN service. If this 
user logs in as gracie@ic:ppp, but does not call the tel^hone number specified 
in column 538, her authorization request is rejected. 

Referring back to FIG. 3, once tiie Selection phase 306 is complete, 
control passes to the Authentication phase 308. In the Authentication phase 308, 
the AAA server 118 searches the user database 309 in the DBMS 120 for the 
combination of the usemame parsed from the log-in and the password presented 
at log-in. If the user requested a proxy server, the proxy is contacted for 
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aiithenticatioxi. A user is authenticated if the usemame and password are found 
in the user database 309. The user is rejected if such information is not found. 

Different security levels can be provided as well. This can depend on the 
type of security scheme being used by the particular client, such as a cryptographic 
authentication device, apublic key cryptography system or the like. For example 
if SecurelD authentication is specified in the user record in the database 309, then 
the AAA server 1 1 8 contacts the ACE/Server for authentication. In a preferred 
embodiment, the present invention provides a user interface so that system 
administrators or the like can specify the level of security required for particular 
services. 

Depending on each specific implementation of the present invention, 
different access rights may be granted depending on the level of security being 
offered. For example, if only a User ID and password are used, access may be 
limited. One the other hand, ifaciyptogn^hic authentication device is used, the 
user may be allowed additional access such as read/write access to a database or 
access beyond a fire wall. 

As step 310 indicates, if a user is not authenticated during the 
Authentication phase 308, a reject answer 3 1 1 is sent back to the client and the 
user is denied access to the network 102. If the user is authenticated, control 
passes to step 312 where the Authorization phase takes place. In the 
Authorization phase 3 12, the AAA server 118 checks the user record in the \iser 
database 309 for the presence of the required pemiit 307, as detemiined from the 
Selection phase 306. As step 3 14 indicates, if the user permit 307 is foimd, the 
user is authorized and control passes to step 3 1 8. If the user is not authorized, the 
client is sent a reject message 316 and the user is denied access to the network 
102. 

System administrators may allow access for a iiser even though the permit 
307 does not match the service in which they are authorized. For example, a 
system administrator may allow a user authorized for high-speed ISDN service to 
access the network 102 using a low-speed asynchronous line. In a preferred 
embodiment, the present invention provides user interface tools that allow users 
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to specify and customize access permits. In one example, this may be 
accomplished by providing a list of valid permits in each user record stored in the 
DBMS 120. 

Once a user is authorized, control passes to the step 318, where the 
Confirmation phase is processed. In the Confirmation phase 318, one or more 
checks are made to assure the user can access the network 102 at this particular 
instant in time. For example, in some systems, it may not be desirable to allow a 
user to log-in to a network more than once at any particular time. This is 
especially true for users such as Internet Service Providers that allow users 
unlimited access to the Internet. 

In one implementation, this is accomplished by including a port limit value 
in each users data record. Each time a tiser attempts access the AAA server 118 
counts the number of connections currently open for that user. This can be 
accomplished by counting thp accounting start and stop events and noting starts 
wi&out corresponding stops* The Confirmation phase 318 then compares this 
nimiber vdth the port limit specified in tiie users data record. 

Additional checks can also be performed during the Confirmation phase 
318. An example of an additional check is a sanity check to determine whether 
the requested service makes sense. For example if a user has signed on using PPP 
but asks for SLIP service, the AAA server 118 determines that the request does 
not make sense and sends a reject message to the client. 

After the Confirmation phase is complete, control passes to step 320. In 
step 320, an answer is constructed and sent back to the client. The answer 
comprises all of the information necessary for the client to access the requested 
service. This information is taken from the selected row in the rules table 305. 
Answers can be standardized giving fixll access to the network 102, or may be 
customized for each user. Once the answer is constructed it is sent to a support 
module, such as the RADIUS support module 230, where the answer is converted 
into the specific authentication transport protocol and sent to the client making the 
request. The process ends as indicated by step 322. 
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It should be noted that according to a preferred embodiment, the AAA 
serverll8canrunonanumberofplatforms. In a preferred embodiment, the 
AAA server code is mitten in a computer language that is transportable to many 
platforms, such as JAVA. In this feshion, the AAA server 118 can be run. 

unmodified on many computer platforms. 

Alloftheuserdata309storedintheDBMS 120 is in a standard DBMS 
format. Accounting data is storedby the AAA server 118 using astandard DBMS 
format. Usingastandard relational database system enables the AAA serverllS 

of the present invention to provide information and reports for many purposes 
including accounting. For example, information sent by clients about session 
estabUshmentandterminationisstoredintheDBMS 120 in the user database 309. 
•nus allows the present invention to provide efficient billing and statistics 
gathering functions. TTie foUovving types of reports can be generated according 

to a preferred embodiment of the present invention: 

. a summary report of activity for a particular 

log-in ID giving the amount of time a particular 
log-in ID has been in use in a given period of time, 
usually since the last billing period; 

• a detail report of activity for a particular log-in 
ID showing each session within a given period; 

• a summary report of activity for all log-in IDs 
associated with a particular customer; 

• a report showing modem/Une utUization 
statistics; 

The present invention may be implemented using hardware, software or 
a combination thereof and may be implemented in a computer system or other 
processing system. In feet, in one embodiment, the invention is directed toward 
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a computer system capable of carrying out the functionality described herein. An 
example computer system 601 is shown in FIG. 6. The computer system 601 
includes one or more processors, such as processor 604. The processor 604 is 
connected to a communication bus 602. Various software embodiments are 
5 described in terms of this example computer system. After reading this 

description, it will become apparent to a person sldUed in the relevant art how to 
implement the invention using other computer systems and/or computer 
architectures. 

Computer system 602 also includes a main memory 606, preferably 
10 random access memory (RAM), and can also include a secondary memory 608. 

The secondary memory 608 can include, for example, ahard disk drive 6 10 and/or 
aremovable storage drive 612, representing a floppy disk drive, a magnetic tape 
drive, an optical disk drive, etc. The removable storage drive 612 reads from 
and/or writes to a removable storage unit 614 in a well known manner. 
15 Removable storage unit 614, represents afloppy disk, magnetic tape, optical disk, 

etc. which is read by and written to by removable storage drive 612. As wUl be 
appreciated, the removable storage unit 614 includes a computer usable storage 
medium having stored therein computer software and/or data. 

In alternative embodiments, secondary memory 608 may include other 
20 similar means for allowing computer programs or other instructions to be loaded 

into computer system 601. Such means can include, for example, a removable 
storage unit 622 and an mterfece 620. Examples of such can include a program 
cartridge and cartridge interfece (such as that found in video game devices), a 
removable memory chip (such as an EPROM, or PROM) and associated socket, 
25 and other removable storage units 622 and interfeccs 620 which allow software 

and data to be transferred from the removable storage unit 622 to computer 
system 601. 

Computer system 601 can also include a communications interface 624. 
Communications interface 624 allows software and data to be transferred between 
30 computer system 601 and external devices. Examples of communications 

interfece 624 can include a modem, a network interface (such as an Ethernet 
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card), a communications port, a PCMCIA slot and card, etc. Software and data 
transferred via communications interfece 624 are inthe form of signals wbich can 
be electronic, electromagnetic, optical or other signals capable of being received 
by communications interfiw^ 624, These signals 626 are provided to 
communications interfeceviaachannel 628. This channel 828 carries signals 626 

and can be implemented using wire or cable, fiber optics, a phone line, a cellular 
phone link, an RF link and other communications channels. 

In this document, the terms "computer program medium" and "computer 
usable medium" are used to generaUy refer to media such as removable storage 
device 612, a hard disk installed in hard disk drive 610, and signals 626. These 
conqniter programproducts are means for providing soflwareto computer system 
601. 

Conqniter programs(also called conq)uter control logic)are stored in main 
memory and/or secondary memory 608. Computer programs can also be received 
via communications interfece 624. Such computer programs, when executed, 
enable the computer system 601 to perform the features of the present invention 
as discussedherein. Inparticular, the computer programs, when executed, enable 
the processor 604 to perform the features of the present invention. Accordingly, 
such computer programs rq)resent controllers of the computer system 60 1 . 

In an embodiment where the invention is implemented using software, the 
software may be stored m a computer program product and loaded into computer 
system 60 1 uang removable storage drive 612, hard drive 6 1 0 or communications 
interfece 624. The control logic (software), when executed by the processor 604, 
causes the processor 604 to perform the fimctiohs of the invention as described 
herein. 

In another embodiment, the invention is implemented primarily inhaidwaie 
using, for example, hardware components such as application specific integrated 
circuits (ASICs). Implementation of the hardware state machine so as to perform 
the functions described herein wUl be apparent to persons skilled in the relevant 
art(s). 
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In yet another embodiment, the invention is implemented using a 
combination of both hardware and software. 

While various embodiments of the present invention have been described 
above, it should be understood that they have been presented by way of example 
only, and not limitation. Thus, the breadth and scope of the present invention 
should not be limited by any of the above-described exemplary embodiments, but 
should be defined only in accordance with the following claims and then: 
equivalents. 
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miat Is Claimed Is: 

1. A system for authenticating and authorizing user access to a 
computer network comprising: 

a database management system; and 
an AAA server comprising: 

a plurality of authentication transport protocol support modules, 
each providing support for receiving requests from clients and sendmg 
answers to clirats in a particular authentication transport protocol; and 

an AA module coupled to said plurality of transport protocol 
modules and said database management ^stem. 

2. The system of claim 1 , wherein said AA module comprises: 

an augmentation module coupled with a parse rules table for parsing the 
request and creating a tuple vector according to said parse rules table; 

a selection module coupled with a rules table for selecting a selected row 
in said rules table by matching one or more tuples in said tuple vector with values 
in said rules table and for retrieving a permit from said selected row; 

an authentication module coupled witii a user database for comparmg one 
or more tiq>les in said tuple vector witii a user record in said database, wherein 
said user record corresponds with a particular uso: specified m said request; and 

an authorization module for autiiorizing said request by comparing said 
permit with a permit stored in said usct record. 

3 . The system of claim 2, wherein said AA module further coinprises: 
aconfirmationmoduleforconfirmmg saidrequestby determining whether 
the user has exceeded a predetermined port limit according to the number of 
current active log on sessions associated with the user and a port limit value stored 
in said user record. 
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4. A process for auflienticating and authoring a request for access 
to a computer network from a client comprising the steps of: 

receiving, at one of a plurality of transport protocol support modules, the 
request, wherein the request is formatted in accordance with a particular 
aullxentication transport protocol corresponding with said one of a plurality of 
transport protocol support modules; 

translating, at said one of a plurality of transport protocol support 
modules, the request from said particular authentication transport protocol into 

a standard format; 

augmenting the request, wherein said augmenting stqp includes parsmg 
said standard format to create a tuple vector in accordance with a parse rules 
table; 

selecting arowin amies table by matching one or more tuples in said tuple 
vector vnih one or more values in said rules table; 

retrieving a pomit from said selected row in said selecting step; 

authenticatmg the request by comparing one or more tuples in said tuple 
vector with a user record in a database management system, wherein, said user 
record corresponds with a particular user specified in the request; 

authorizing the request by comparing said permit from said retrieving step 
with a permit stored in said user record; 

constructing an answer to the client in accordance with results from said 
augmentation, selection, authentication and authorization steps; and 

sending said answer to the client. 

5. The process of claun 4, further comprismg the steps of: 
confirming tiie request by determining whether said particular user has exceeded 
a predetermined port limit according to tiie number of current active log on 
sessions associated witii said particular user and a port limit value stored in said 
user record; and 

sending an authorization response to tiie client if said confirming step 
indicates that said port limit value has not been exceeded; and 
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sendingareject message to theclient if saidconfitming Step indicates that 
said port Umit value has been exceeded. 

6. The process of claim 4, wherein said constructing step comprises 
the step of constructing a reject message if said authenticating step mdicates a 
mismatch between said one or more tuples and said user record. 

7. The process of claim 4, wherein said sending step comprises the 
step of sending a reject message to the client if said authorization step indicates 
a mismatch between said permit from said retrieving step and said permit stored 
in said vsa record. 

8. The process of claim 4, wherem said sending step conq>rises the 
step of sending an appropriate aufliorization response to the cUent, if a match is 
found in said auflienticating and said authorizing stqw. said appropriate 
authorization response includes information from said selected row in said rules 
table. 

9. The process of claim 4, further comprising the step of providing 
accounting data to the user record stored in the database, said accounting data 
including user access time and sarvices accessed, 

10. A computer program product comprising a con^uter useable 
medium having computer program logic stored thereui. said computer program 
logic for authenticating and authorizing a request for access to a computer 
network from a cUent, wherein said computer program logic comprises: 

means for enabling the computer to receive, at one of a pluraUty of 
transport protocol support modules, the request, wherein the request is formatted 
in accordance with a particular authentication transport protocol corresponding 
with said one of a plurality of transport protocol support modules; 
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means for enabling the computer to translate, at said one of a plurality of 
transport protocol support modules, the request from said particular 
authentication transport protocol into a standard format; 

means for enabling tiie computer to augment the request, wherein said 
augmenting means includes means for enabling the computer to parse said 
standard format and create a tuple vector in accordance with a parse rules table; 

means for enabling the computer to select a row in a rules table by 
matching one or more tuples in said tuple vector with one or more values in said 
rules table; 

means for enabling the computer to retrieve a permit from said selected 

row; 

means for enabling the computer to authenticate the request by comparing 
one or more tuples in said tuple vector with a user record in a database 
management system, whraein said user record corresponds with a particular user 
specified in the request; 

means for enabling the computer to authorize the request by comparing 
said permit from said retrieving means with a permit stored in said user record; 

means for enabling the computer to constmct an answer to the client in 
accordance with results from said augmentation, selection, authentication and 
authorization means; and 

means for enabling the computer to send said answer to the client. 

1 1 . The computer program product of claim 1 0, wherein said computer 
program logic further comprises: 

means for enabling the computer to confirm the request by determining 
whether said partiuclar user has exceeded a predetermined port limit according to 
the number of current active log on sessions associated with said particular user 
and a port limit value stored in said user record; and 

means for enabling the computer to send an authori2^tion response to the 
client, if said confirming means indicates that said port limit value has not been 
exceeded; and 
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means for enabling computer to send a reject message to the client if 
said confirming means indicates that said port limit value has been exceeded. 

12. The conq>uter program product of claim 10, wherein said 
5 constructing means con^rises means for enabling the conq>uter to construct a 

rqectmessageifsaidauflienticatingmeansindicatesamismatchbetweensaidone 

or more tuples and said user record. 

13. The computer program product of claim lO.^^^^erein said sending 
10 means comprises means for enabUng the computer to send a reject message to the 

cUent if said authorization means indicates amismatch between said permit from 
said retrieving means and said permit stored in said user record. 

14. Theconqmterpiogramproductof claim 10, whereinsaidsending 
15 means comprises means for enabling the computer to send an appropriate 

authorization response to Ae chart, if a match is found m said authenticating 
means and said authorizing means, said appropriate authorization response 
includes information from said selected row in said rules table. 

20 15. Theco0q)uterprogramproductof claim 10, v^ereinsaidcomputer 

program logic further comprises: 

means for enabling the computer to provide accounting data to the user 
record stored in the database, said accounting data including user access time and 
services accessed. 
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